Rubric-Based RL 十月洞察

最近一个月，一直在关注 rubric-based rl 领域的相关工作。趁着假期，把读过的几篇论文整理一下，尝试重新梳理出一张地图。

先梳理一遍 Pipeline, 以常见的rubric 评分形式为例：针对一个 Prompt，先准备一组 rubric，也就是这道题的评分标准；Policy则对同一个模型Prompt采样，生成多个回答；Judge 结合问题、回答和 rubric，判断每条标准是否被满足，再将这些得分汇总，这样每个回答就得到了一个 reward；GRPO利用同一个问题下各个回答的相对奖励计算 advantage, 用于更新 policy, 然后进入下一轮采样和训练。

上述过程大致可以对应为

$$\text{Prompt} \rightarrow \text{Rubric} \rightarrow \text{Judge} \rightarrow \text{Reward} \rightarrow \text{GRPO} \rightarrow \text{Policy}$$

静态 Rubric：从评测到训练

Rubric 最早用于开放问题的评测，HealthBench是OpenAI 在 25年3月发布的医学评测Bench。医生为每段医疗对话编写具体的评分标准，列出回答应包含的内容和应避免的问题，并设置相应权重。模型 Judge 按这些标准逐项判断，再汇总为得分。这些标准针对不同对话分别制定，在评测时保持固定。

Rubrics as Rewards（RaR，ICLR 2026）是首先将 Rubric 用于RL 训练的代表性工作之一。RaR 先利用问题和参考答案，让 LLM 生成一组评分标准。每条标准包含一个 criterion 和对应的权重，例如要求回答包含某个关键事实、解释推理依据，或避免某种常见错误。这里的 rubric 是静态的：不同问题有各自的 Rubric，但同一问题的标准在 policy 训练过程中保持不变。

这其中就体现出静态 rubric 带来的问题：policy 在不断变化，旧的rubric已经无法区分回答。这可能是policy 已经学会利用rubric, 而不是 policy 真的变聪明了。

Rubric: 评分标准如何生成

在 pipeline 的第一步中，我们需要为每一个 prompt 准备一组评分标准。现有的生成 rubric 的方法大致分为四类：专家编写(HealthBench), 设计提示词工程直接用LLM生成(RaR), 测试期动态优化(RubricRAG)和基于偏好对的训练方法(OpenRubrics)。

本节的讨论重心不放在这些现有方法的区别上(写这篇 Blog 的时候才注意到这已然是一个有很多 work 的小领域，我还不太了解)，只能重点介绍一些我近期阅读过的工作中一些普遍使用的方法。

RaR就是典型的Prompt Engineering 的方法：设计一系列生成 rubric 的要点，然后把问题和参考答案给LLM, LLM 输出 rubric。参考答案在这里提供了回答应覆盖哪些内容的依据，生成时不需要先看当前 policy 的回答。

EvoRubric(202605, Tongyi)和DynamicRubric(202607, WeChat) 都让生成器看到问题及当前 policy 采样的一组回答，再生成能区分这些回答的标准。比如，当几条回答都包含基本事实时，标准可以进一步检查解释是否完整、是否遗漏关键条件。EvoRubric 还会输入从 Memory Pool 取出的历史标准。

CARE(EMNLP’26) 同样利用当前回答，但采用的是对照修订：从已有 rubric 出发，把当前得分最高的 rollout 与 frontier model 生成的高质量 anchor 回答比较。如果高分来自钻漏洞，就修订对应标准或增加约束；否则，将两条回答之间的质量差距写成新的标准。

到了多步任务，生成器还会利用执行上下文。ARCO(202606, RUC) 根据问题、此前的轨迹和当前 action，为每一步生成局部标准；DRACO(202609, CMU) 则先根据任务生成基础标准，再查看完整 rollout，针对其中暴露的问题补充标准，最后将同组 rollout 的候选标准合并为一套共享 rubric。两者都利用轨迹信息，但一个检查当前步骤，一个为整条轨迹建立评分依据

GenRubric(202608, THU)则专门训练一个自进化无监督的Rubric Generator。具体来说，对同一个问题采样多组 rubric，让固定的 LLM 分别按每组 rubric 生成回答，再用所有候选 rubric 对这些回答交叉评分。作者的想法是：一组覆盖较全面的 rubric，指导生成的回答在其他 rubric 下也应该拿到高分。但是，他们只验证这样生成的 Rubric 和专家写的 rubric 相比好不好，并没有验证这样生成的 rubric 对RL 训练是有益的。

这些方案还需要检查一个共同的问题：Rubric 是否真的代表了真正的好回答。ImpossibleRubrics(202609, NUS) 在证据不足、前提错误等任务上，让 attacker 直接读取 rubric，专门生成最容易拿高分的回答。在一些样例中，违反证据的回答反而比承认证据不足的回答得分更高。

标准生成之后，下一步看 Judge 能否按这些标准进行判分。

Judge: 如何判断回答是否满足标准

Rubric 写出要检查什么，Judge 则结合问题、回答和标准，给出具体判断。主流的方案还是采用LLM-as-Judge 但也有一些有意思的方案值得分享。

Judging LLM-as-a-Judge(EMNLP’26) 正面质疑 rubric-based RL 用LLM 作为Judge。作者训练了一个只看 rubric 文本的分类器，不输入回答和上下文，也能在所测数据上超过随机水平地预测 Judge 的判词。他们给出的解释是Rubric 文本并不中立，其中带有影响0/1判断的伪影。

Small Language Models as Judges(EMNLP’26) 比较了同一个 backbone 的三种判分方式。Generative 生成 Yes/No 判词；Logprob 直接比较 Yes 和 No 的输出概率；Probe 则输入问题、回答和单条 criterion，从 hidden state 读取判断。Probe 固定 backbone，只训练一个轻量的线性分类头，监督标签来自 GPT-4o，RL 时用预测的满足概率作为逐项得分。后两种方式省去了生成判词和解析文本的过程。

ARCO 也从模型表示中读取分数，但采用的是可共同训练的评分头。它先生成当前步骤的 rubric，再将上下文、action 和 rubric 一起编码，输出各项 criterion 的连续分数。

在 Judge 这个节点上，我认为Judge 对 RL 的影响和对评测的影响应该要分开看。一个好Judge 并不意味应用在RL 时就能取得好效果。

Reward: 评分怎么用于策略更新

Judge 给出判分之后，还要决定各项分数怎样汇总，以及这些奖励怎样用于更新 policy。前面介绍的工作可以从这两个问题来比较：一类主要为整个回答提供奖励，另一类进一步处理多步任务中的 credit assignment，也就是哪些步骤应该得到更多的强化或惩罚。

RaR 的显式聚合方案、DynamicRubric 和 Small Language Models as Judges 都将逐项得分按权重汇总、归一化，为每个回答得到一个标量 reward。Judge 输出可以是 0/1，也可以是预测的满足概率；汇总后，都用整个回答的分数计算组内相对 advantage，再用于 GRPO 更新。RaR 的隐式方案则让 Judge 直接给出总分。

多步任务还需要考虑总分怎样分配到不同决策。在通常的轨迹级 GRPO 中，同一条轨迹的各个生成 token 使用同一个 advantage。即使 rubric 分别检查了检索、推理和最终回答，汇总后的学习信号仍可能是统一的。例如，一条轨迹前面找到了正确证据，最后却给出错误结论，轨迹总分本身并没有说明各步应承担多少责任。

DRACO 先根据适用标准的满足与违反情况，计算轨迹 reward 和组内 advantage，再让 Judge 指出每条判词对应哪些步骤。它据此估计步骤质量：正 advantage 的轨迹将更多强化分配给较好的步骤，负 advantage 的轨迹将更多惩罚分配给较差的步骤，并按步骤长度调整 token 上的 advantage。重分配保留原 advantage 的正负方向，以及按 token 求和的总量。训练时不需要任务成功的真实标签，但步骤归因仍依赖 Judge。

ARCO 则直接学习逐步分数。它将当前步骤各项 criterion 的连续分数取平均，得到 step reward，并用整条轨迹的逐步分数之和逼近终局的 0/1 结果。策略更新时，每一步使用从该步开始的后续累计奖励，再减去相应步骤位置的基线，形成 advantage。它与 DRACO 的差别在于反馈来源：ARCO 用终局结果约束学习出的逐步分数，DRACO 用 rubric 判词及其步骤引用重分配轨迹 advantage。

这块的工作又落回 Agentic 上的 reward 设计的工作，细粒度。

训练闭环：动态 Rubric 和 Policy共进化

Policy 更新之后，下一轮生成的回答也会变化：一些原有标准可能变得容易满足，一些评分漏洞可能被反复利用。

EvoRubric 和 DynamicRubric 都将 Rubric Generator 与回答 policy 放进共同更新的闭环：当前回答用于训练生成器，生成的标准再用于训练回答模型。它们的训练结构有所不同。EvoRubric 让同一个模型通过不同提示承担 Reasoner 和 Generator 两种角色，两个角色共享参数、使用各自的奖励；DynamicRubric 则交替更新两个模型，先固定 policy 训练 Generator，再固定 Generator 训练 policy，执行逐项判断的 Verifier 保持冻结。

这两篇工作都认为好的 rubric 应该能区分当前回答。EvoRubric过滤组内得分完全相同的标准，并奖励一组 rubric 与其他候选组的评分共识；通过检验的 rubric 进入 Memory Pool，参与回答模型的奖励。DynamicRubric 则将区分度奖励与已有排序的 anchor 回答结合：生成器根据当前回答写 rubric，再用这些rubric给 anchor 打分，检查评分方向是否符合参考排序。

CARE 在训练过程中，用每一轮得分最高的 rollout 和 anchor 做对比：发现此 rollout 在钻 rubric 的漏洞，就修复漏洞; 反之，就将这个 rollout 和 anchor 的质量差异变成新的 rubric。、

ARCO 将共同更新扩展到生成 rubric 和执行评分两部分。它的评价模型内部共享一个 backbone，分别负责生成 rubric 和输出连续分数；经过教师数据的监督初始化后，评价模型与 policy 在同一批当前 rollout 上更新。终局结果约束逐步分数之和，KL 则约束标准文本相对初始化模型的偏移。这样，policy 的新行为会进入评价模型的训练，更新后的评价模型又为后续 policy 学习提供逐步奖励。

Insight and Action

1. 用树模型做 Judge 这件事和小模型做 Judge 异曲同工，近期会=关注 Judge 这个环节的事情。
2. 让 Rubric 有区分度这件事，在策略更新上有道理。但是有一些模型已经学会某种行为后，我们要是删除没有方差的 rubric 后如何保证模型不退化呢。所以我觉得这件事可以验证一下，保留长期静态的 rubric 结合有区分度的 rubric，这样是否会减少模型退化.(如果退化现象确实存在)
3. Rubric 生成的好不好，评测好和RL有益是两个评价角度。其实可以说，专家写的 rubric最权威，但不一定适合 RL。

结尾

这是我最近研究过程中的一点思考和总结，我更倾向于在 pipeline 中的某个节点中做一些工作，所以我选择了这样的分类归纳方式，希望能借此给自己带来一些灵感。

相关工作：这是文献阅读时的随笔

Rubrics as Rewards(ICLR’26) 是 one of the first works。 RaR 首次将rollout在 Rubric 中 获得的分数作为GRPO的奖励信号进行 RL。当前是通过 Prompt Engineering 的形式，为每个 query 生成一组静态的 Rubric, 其中包含多对(criterion, weight)对, 特别的标准是二元的。

Judging LLM-as-a-Judge(EMNLP’26)质疑 rubric-based RL 中用LLM 作为Judge的部分。他们发现，只给Judge看rubric, 不用看回答和上下文，就能做出超过随机猜测的表现。他们给出得解释是：Rubric 文本不中立，其中带有影响0/1判断的伪影。

静态 Rubric 随着 policy 训练会逐渐被 exploit

CARE(EMNLP’26)开始做动态rubric。CARE 引入 frontier model 做为高质量anchor. 具体来说：CARE 在训练过程中，用每一轮得分最高的 rollout 和 anchor 做对比：发现此 rollout 在钻 rubric 的漏洞，就修复漏洞; 反之，就将这个 rollout 和 anchor 的质量差异变成新的 rubric。

Small Language Models as Judges(EMNLP’26) 继续关注 Judge。他们提出用小模型的 hidden-state Probe代替大模型生成式 Judge 做 rubric-based RL 奖励。

EvoRubric(202605, Tongyi)和DynamicRubric(202607, WeChat)两篇工作同时关注动态 rubric。他们同时训练 Rubric Generator 和 Policy，目的是生成有区分度的 rubric, 促进 Policy 的 GRPO训练。

Reward Hacking in Rubric-based RL(202605, Scale AI) 关注 Rubric 本身的设计，他们发现很多 Reward Hacking 的形式发生在 Verifier 判断漏洞和模型仍然可以利用 Rubric 本身的设计局限。

CHERRL(202606, THU) 构建了一个可控的 Rubric-Based RL reward hacking 实验环境：通过在正常 Judge 奖励上人为注入已知 bias，复现并定位 reward hacking 的出现过程。作者发现，bias 与正常任务行为越相关，就越容易被模型发现；bias 行为越容易生成，就越容易被快速利用。

ARCO(202606, RUC)训练一个backbone+两个头，分别负责生成rubric 和 打分并与策略模型在同一批数据上更新，使Rubric和Judge随Policy行为的改善而共同演化。

GenRubric(202608, THU)则专注训练一个自进化无监督的Rubric Generator。作者认为，一组好的 rubric 应该具有 cross-rubric generalization 的答案。简单来说，在一组优秀的 rubric 指导下生成的答案，拿到其他 rubric 下评分，也能得高分。但是，他们只验证这样生成的 Rubric 和专家写的 rubric 相比好不好，并没有验证这样生成的 rubric 在 RL 训练中是否也好。

DRACO(202609, CMU) 先根据当前 rollout 动态生成“这条轨迹应该满足什么标准”，再用这些 rubric 给整条 trajectory 打分，最后根据每条 rubric 指向了哪些 step，把 trajectory-level GRPO advantage 重新分配到不同 step。这篇工作回到了 Credit Assignment 这条路线上，开始关注细粒度奖励。

ImpossibleRubrics(202609, NUS)关注 Rubric 生成的不好，导致 hack reward 的问题。这篇工作发现，LLM 自动生成的 rubric 自己就可能写错奖励目标。作者让一个 attacker 直接看 rubric、专门生成“最容易拿高分”的答案，结果这些答案有时虽然违反证据，反而比诚实回答得分更高。